Overview of Linux Patch Management

Only those Linux machines that meet the minimum requirements are eligible to be scanned and patched by an agent. See the System Requirements for complete information.

Linux machines are scanned and patched using agents. The process depends on whether you are using the new contentless Linux patching method or the old content-based method. See Linux Contentless Patching for information about this change.

Watch a related video (02:44)

  1. Identify your Linux machines.
    • If you know the identities or whereabouts of all your Linux machines, you can create a Linux machine group.
    • If you are unsure about the identities and locations of all your Linux machines, perform a power status scan on the My Domain or Entire Network group. The scan will identify the OS type of each machine in the group and your Linux machines will be displayed on the Linux patch tab in Machine View.
  2. Create one or more Linux patch groups and configurations.
    • Create a Linux patch group: This is optional but can give you greater control over your scans and deployments, enabling you to scan for (content-based only) or deploy a particular set of patches. You create separate patch groups for contentless Linux patching and for content-based Linux patching.
    • Create a Linux patch scan configuration (content-based only): You use this configuration to specify exactly how your Linux machines will be scanned. Contentless patching always performs a patch scan for all missing patches before any deployment method so does not require a patch scan configuration.
    • Create a Linux patch deployment configuration: You use this configuration to specify exactly how patches will be deployed to your Linux machines. You create separate patch deployment configurations for contentless Linux patching and for content-based Linux patching.
  3. Create one or more agent policies.

    4. An agent policy defines exactly what an agent can or cannot do. You will create one or more Linux patch tasks in the agent policy. In each task, you specify when the task will run on an agent machine and which configurations should be used during the scan and deployment processes.

    It is perfectly fine to mix Windows tasks and Linux tasks in the same agent policy. Windows tasks will be ignored by your Linux machines, and vice versa.

  4. Install the agent policy.

    5. Each Linux target machine must be properly configured before you can perform a push install of an agent. See System Requirements for more details.

    One option is to perform a "push install" of the agent from the Security Controls console. You can do this a couple of different ways:

    • Within your Linux machine group, select the machines in the bottom pane and then click Install / Reinstall agent.
    • In Machine View, right-click the Linux machines and install the desired agent policy.

      • If you performed a power status scan on your Linux machines, you can also perform this step from the Results list in the navigation pane.

    Another option is to manually install an agent on each of your Linux machines. For details, see Manually Installing Agents.

  5. Use the agent.

    6. The agent will automatically perform its tasks and report the results to the console. You can use Machine View or Scan View to manage the machines that are running an agent policy. If you want to manually control the agent, you do so using a command line utility. For details, see Using an Agent on a Target Machine.

    When a Linux agent needs to deploy a patch, it does so using Yellowdog Updater, Modified (YUM). YUM is a command-line utility that is used for retrieving, installing and managing RPM packages. If you have Linux client machines that reside in a disconnected network, the agent will not be able to utilize YUM and you must set up one or more local repositories.

Modules and versions

You can't always install the latest version of a package on a Linux machine.

For Red Hat Linux and distributions derived from Red Hat, a machine may have modules installed that have several streams, only one of which can be enabled on a machine.

module A has three streams, only one of which is enabled on the machine

Consider the case where an advisory wants to update a package in one of these types of module.

Update a package within a module that has several streams

If the new version of the package is for a specific stream that differs from the enabled stream on a machine, then the updated package is incompatible and cannot be installed. As a result, a later version of a package for a module will be available than the version that can be installed on a machine.

The new package depends is for a different stream of the module than the enabled stream on the machine, so the new package cannot be installed

Similarly, it may appear that the latest package hasn't been installed because of module dependencies. For example, the module perl-DBD-SQLite appears to have several module updates for the perl-DBD-SQLite package:

  • perl-DBD-SQLite-0:1.58-2.module+el8.1.0+2940+55ca6856.x86_64
  • perl-DBD-SQLite-0:1.58-2.module+el8.1.0+2940+f62455ee.x86_64
  • perl-DBD-SQLite-0:1.58-2.module+el8.2.0+4265+ff794501.x86_64
  • perl-DBD-SQLite-0:1.58-2.module+el8.6.0+13408+461b4ab5.x86_64

However, each of these packages has a dependency on a specific perl stream. The first can be installed only when perl:5.24 is enabled, and the last only when perl:5.32 is enabled, so it may be that what appears to be the latest version of a package cannot be installed on a specific machine.